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DOCUMENT-IDENTIFIER: US 6578014 Bl 

TITLE: Method and apparatus for post-transaction pricing system 



Abstract Text (1) : 

The present invention is a method and apparatus for effectuating post- transaction- 
priced transactions of information, "goods, and services in exchange for money or 
its equivalent (such as credits) - The invention allows prospective sellers of 
information, goods and services to offer those items globally to potential buyers, 
for buyers to make item requests of sellers, for sellers and buyers conveniently to 
search for r elevan t buyer and seller information, for sellers to provide items to 
^Wr^Wf^^^^F^^^^^rW^^^^^^ik amount, and for buyers to decide 
how much to pay for those items after having received them- The method and 
apparatus of the present invention have applications on the internet as well as 
conventional communications systems such as voice telephony. In a preferred 
embodiment, the method and apparatus of the present invention include mechanisms 
through which information about participants and previous transactions is revealed 
in such a way as to encourage buyers to pay a fair amount for the items provided, 
and to encourage sellers to provide items that are of high value to the buyers to 
whom they provide those items. Specifically, the system stores information 
regarding previous transactions and makes this information available to 
participants, so that they are able to intelligently decide which participants are 
worth transacting with. For example, a buyer who routinely pays nothing for items 
will scon have difficulty finding sellers interested in selling him/her items, 
while a buyer who consistently pays a fair price for items will be able to expect a 
steady stream of items. Similarly, a seller who consistently provides items which 
buyers are willing to pay large amounts for will have greater ability to provide 
items to buyers in the future, while a seller who provides items which buyers 
generally find worthless will have great difficulty finding any buyers to provide 
items to. 

Application Filing Date (1) : 
20000413 

Brief Summary Text (7) : 

Buyers and sellers traditionally exchange information, goods, and services for 
money through one of several methods. In the most common of these, the seller sets 
the price, and the buyer either accepts that price or doesn't (for example, retail, 
or most classified ads). In another common method, the buyer and seller agree to a 
price (for example, a flea market, or a classified ad which includes x or best 
offer'). Sometimes buyers compete and the highest price offered wins (for example, 
a standard auction, a reverse auction, or a Dutch auction) . Sometimes sellers 
compete for a given buyer (for example, a 'wanted to buy* classified ad) . Other 
commerce systems are exchange-driven, and j2M^|£5^ 

orderly ma r k e t pla c e-^( s u c h as the NASDAQ or'^he^New^Yo'rk Stock Exchange)". In all of 
^^^^BSpeSSs^I^r^p'rotocols, the buyer and seller agree to the price and other 
payment terms before the information, goods, and services are provided. Several 
U.S. patents relate to on-line electronic communications and processing of 
transactions between multiple buyers and sellers with these various buyer-seller 
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protocols. But for every single one of these, the buyer and seller do agree to a 
price before the transaction is completed; indeed, if an agreement on price and 
other terms cannot be reached, the transaction does not-roccur. • ■ > ^ -- • • • . . 

Brief Summary Text (25): 

The present invention is a method and apparatus for effectuating post-transaction- 
priced transactions of goods, services, and information in exchange for money or 
its equivalent (such as credits) . The invention allows prospective sellers of 
information, goods and services to offer those items globally to potential buyers, 
for buyers to make item requests of sel lers, for sellers and buyers conveniently to 
^Tggtt ^W-. r-PAfcyjan^bi^etrand^ for sellers to provide items to 

^ yer g ^STSouWnTgulTr^nO^t a specific payment amount, and for buyers to decide 
how much to pay for those items after having received them. 

Brief Summary Text (26) : 

The method and apparatus of the present invention have applications on the internet 
as well as conventional communications systems such as voice telephony. Each 
participant can communicate with the system from remote terminals adapted to access 
communication links and the system may in clud e remote terminals adapted fff-gP™** 
of a remote database . The syst^aaiga a^^ 

i-r a n* a rtion.-in.£o.Bm ateTOn. The ■ ggUgBa'steft isWggcebs ed via a validation procedure to 
pyrmit' transactions in an interactive online mode between users during interactive 
transaction sessions wherein one participant to the transaction is specifically 
selected by the other participant. The system permits concurrent interactive 
business transaction sessions between different participants. 



Brief Summary Text (27) : 

In one embodiment of the present invention, communications between buyers and 
sellers are conducted using an electronic network and a system operator. A seller 
who wishes to sell an item accesses the system operator located at a remote server. 
The seller then specifies the item he/she wishes to sell, x se.ar.ch£3. r f.o,r-b.uy.e 1 Eis m w i hg»» 
mi Qh±-be-^n4^e.r^s.ted in rieeegKvainW^^ a description of the 

it JS^SPfSF$l?p?!^ of the item or the 

item itself (if the item is information) to those buyers. For example, a typical 
item could be a well-researched article about a specific subject, on which the 
seller is an expert. The seller searches anc^dej^ff^-orcemo^ 
might be * nt>r M tpd in th'elalatelJdtJeWan 'dWhyrPeither provides the article or a 
MtaA aMMamt mami^iSPBw/er (s ) . Under the present invention, the information may 
be transmitted via numerous means including a world wide web interface, email, 
voicemail, facsimile, or postal mail. Alternatively, the information may be 
developed while the seller is online with the system operator. The system operator 
then assigns a unique tracking ID to the item and the item is sent to each buyer 
that the seller specified. Subsequently, the buyer logs on to the system, views 
items that have been provided to him/her, and optionally specifies payment amounts 
for those items or requests additional information from the seller (s). After the 
buyer has sent the payment to the system operator to cover the item(s) , the system 
operator sends a payment to the seller (s). Various methods of payment, may be 
utilized by the invention,"'including credit cards, personal checks, electronic 
funds transfer, debit cards, digital cash, and escrow accounts. 

Drawing Description Text (7) : 

FIG. 5a illustrates one embodiment of the Items database . 
Drawing Description Text (8) : 

FIG. 5b illustrates another embodiment of the Items database in which additional 
item information is included. 



Drawing Description Text (9) : 

FIG. 6a illustrates one embodiment of the Sellers database . 
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Drawing Description Text (10) : 

FIG. 6b illustrates another embodiment of the Sellers database in which additional 

• ....seller.- information is. included. ^r,. J .. 1)! ,^a.ih..^;.w...v.«- . &m ^..n.-*.- . 

Drawing Description Text (11): 

FIG. 7a illustrates one embodiment of the Buyers database . 
Drawing Description Text (12): 

FIG. 7b illustrates another embodiment of the Buyers database in which additional 
buyer information is included. 

Drawing Description Text (13): 

FIG. 8 illustrates one embodiment of the Buyer Item Requests database . 
Drawing Description Text (14): 

FIG. 9 illustrates one embodiment of the System Payments to Sellers database ■ 
Drawing Description Text (15): 

FIG. 10 illustrates one embodiment of the Buyer Payments to System database . 
Drawing Description Text (16) : 

FIG. 11 illustrates one embodiment of the Kicked Out database . 
Drawing Description Text (21) : 

FIG. 16 illustrates one embodiment of the Buyer Searches For Sellers form, which 
enables buyers to search the database to find sellers who might have items, 
demographics and/or areas of expertise of interest to the buyers. 

Drawing Description Text (27) : 

FIG. 22 illustrates one embodiment of the Seller Searches For Buyers form, which 
enables sellers to search the database to find buyers who might want the items the 
sellers have or can obtain. 

Detailed Description Text (2) : 

Throughout this document, the term "item" is used to mean information, goods and/or 
services that are being provided by the buyer and to the seller in a single 
transaction. An item can be anything of potential value. Note that the first type 
of item, information, will sometimes be a Pqij^g^ ^^Qthe ac t u a ^^ ^&g^g-^^gg ^ ex ■ a 
web site location or the name of a boofeociigg^e^p^^ 
information itself. In a preferred embodiment, a single item can include 
information, goods, services, or any combination of the three. In other words, 
"item" for the purposes of the present invention can actually consist of multiple 
items within a single transaction. 

Detailed Description Text (11) : 

The method and apparatus of the present invention will now be discussed with 
reference to FIGS. 1, 2, 3, and 4. In a preferred embodiment, the present invention 
includes s v s tern Qq fira^]p 200, buye r ' s inte rf ace. 300, seller's interface 400 and 
associated Gt^SmcSB^^ v*^ 

Detailed Description Text (12): 

The system architecture of a preferred embodiment of the apparatus and method of 
the present invention is illustrated with reference to FIGS. 1 through 4. As shown 
in FIG. 1, the apparatus of the present invention comprises system operator 200, 
buyer's interface 300, and seller's interface .400. System operator 200, buyer's 
interface 300, and seller's interface 400 are each connected via an Internet 
connection using a modem (102 for sellers, 104 for buyers) . A variety of internet- 
enabled communications systems could be utilized to transfer data between the host 
system and the various remote users of the system, such as a public switched phone 
network, a cable network, data lines, cellular, Personal Communication Systems 
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("PCS") , microwave, or satellite networks. Buyer's interface 300 and seller's 
interface 400 are the input and output gateways for communications with system 
> operator.^200 .^The.uar rows indicate information being passed through; the^sys.tem: for , 
example, information flows from seller's interface 400 to seller's modem 102 to 
system operator 200 when a seller registers (FIG. 20) or fills out the form 
providing an item to one or more buyers (FIG. 23), and information flows in the 
opposite direction when aseUerrun^-^^tp^heck his/her account balance 

(FIG. 25) or to look at S!S3S^mrffigs (FIG. ZV) . 

Detailed Description Text (17): 

As shown in FIG. 2, system operator 200 includes central processor (CPU) 202, RAM 
206, ROM 208, payment processor 212, clock 204, operating system 210, network 
interface 214, and data storage device 220. As is conventionally known in the art, 
the ROM provides software instructions to perform basic operations upon power up of 
the system. Once the system receives these instructions, the CPU reads operating 
system instructions stored on disk to configure the system and to permit execution 
of various applications programs. Other applications conventionally known may be 
included in the software environment. A personal computer or computer workstation 
with sufficient memory and processing capability may be used as system operator 
200. In one embodiment system operator 200 operates as a server, both receiving 
information from and transmitting information to buyers and sellers. System 
operator 200 must be capable of high volume transaction processing, performing a 
significant, nurnberofmathematical calculations in processing communications and 
^^^l^^MsM^\tx<^^S t^^i- croprocessor such as Intel's Pentium III, or a similar 
^B5£roprocessor from Advanced Micro Devices or another vendor, may be used for. CPU 
202. 

Detailed Description Text (19): 

Data storage device 220 may include hard disk magnetic or optical storage units, as 
well as CD-ROM drives or flash memory. Data storage device 220 contains databases 
used in the p rocess jujywoj^^r ansactions and thestori^^and^^^o^jj^^^^^^^^^ 
information, jiggSiBf^^ s e 

700, Buyer Item Requests 800, System Payments to Sellers Database 900, Buyer 
Payments to System Database 1000, and Kicked Out Database 1100. The data 
illustrated in FIGS. 5-11 are representative of a preferred embodiment but might 
differ somewhat in any specific implementation. In a preferred embodiment a 
commercially available database management system with scalability and flexibility, 
such as Oracle's Oracle8 or Microsoft's SQL Server, is used to create and manage 
these databases . Security is implemented to prevent misuse by participants. Steps 
are taken to keep all information secure, especially payment data. In a preferred 
embodiment, these databases are all in the same Database Management System (DBMS), 
while in another embodiment they are distributed among multiple DBMSes. In some 
embodiments, some of the information which in a preferred embodiment is stored in 
the databases in data storage device 220 is instead stored on the buyers' and 
sellers' Data Storage Devices 320 (FIG. 3) and 420 (FIG. 4), respectively. This 
could be done for performance, security, or other reasons. 

Detailed Description Text (21): 

While the above embodiment describes a single computer acting as system operator 
200, those skilled in the art will realize that the functionality can be 
distributed over a plurality of computers. In one embodiment, system operator 200 
is configured in a distributed architecture, wherein the databases and processors 
are housed in separate units or locations. Some system operator components perform 
the primary processing functions and contain at a minimum RAM, ROM, and a general 
. processor. Each of these components can be attached to a Wire Area Network (VAN) 
hub serving as the primary communication link with the other components and 
interface devices. The WAN hub may have minimal processing capability itself, 
serving primarily as a communications router. Those skilled in the art will 
appreciate that an almost unlimited number of system operators may be supported. 
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Detailed Description Text (25) : 

Referring now to FIG. 3, there is described buyer's interface 300 which includes 
, central ..pr.ocessing i ,unit Jt ;(GRU)^312 7 , RAM. 302, ROM .304,.. clock . 3 06,.. video .driver , 308 
display device 340, communications port 314, input device 350, modem 104, and data 
storage device 320. An Intel microprocessor such the Pentium III may be used for 
CPU 312. Clock 306 is a standard chip-based clock which can serve to time-stamp any 
specific action a buyer takes, such as assigning a payment amount or asking a 
seller a question. Data storage device 320 is a conventional magnetic-based hard 
disk storage unit such as those manufactured by Seagate or Quantum. In some 
embodiments, some of the information which in a preferred embodiment is stored in 
the databases in data storage device 220 is instead stored on the buyers' Data 
Storage Device 320. This could be done for performance, security, or other reasons. 



Detailed Description Text (26): 

Referring now to FIG. 4, there is described seller's interface 400 which includes 
central processing unit (CPU) 412, RAM 402, ROM 404, clock 406, video driver 408, 
display device 440, communications port 414, input device 450, modem 102, and data 
storage device 420. An Intel microprocessor such the Pentium III may be used for 
CPU 412. Clock 406 is a standard chip-based clock which can serve to time-stamp any 
specific action a seller takes, such as providing an item to a buyer or responding 
to a buyer's question about an item. Data storage device 4 20 is a conventional 
magnetic-based hard disk storage unit such as those manufactured by Seagate or 
Quantum. In some embodiments, some of the information which in a preferred 
embodiment is stored in the databases in data storage device 220 (FIG. 2) is 
instead stored on the sellers' Data Storage Device 420. This could be done for. 
performance, security, or other reasons. 

Detailed Description Text (30): 

In one embodiment, a buyer or a seller can put certain data (especially that data 
which relates to one's own transactions) in a format easy to copy to other 
applications (e.g. report writing, or saving as a spreadsheet file or database 
file) . 

Detailed Description Text (31): 

Referring to FIG. 5a, Items Database 500 maintains data on items that sellers are 
willing to sell, such as Item ID 502, Buyer ID 504, Seller ID 506. Item 508, Date 
Item Description Provided 510, Date Item Provided 512, Payment Amount 514, Payment 
Date 516, Buyer Payments To System ID 518, System Payments To Sellers ID 520, 
Status 522 and Correspondence 524. In a preferred embodiment, Items Database 500 
has one record (row) for each item. Item ID 502 is a unique identifier for the 
item. Buyer ID 504 stores the numerical ID from ^u^ejg^ re spondi ng 

to the buyer for this transaction. Seller ID 506 Stores the numerical ID from 
Sellers Database 600 corresponding to the seller for this transaction. Item 508 
stores a description of the item, as it was entered by the seller through Seller 
Provides Item form 2300 (FIG. 23). If the item is information (as opposed to goods 

or ser vice s]^, this data may be the actual information the item consists of; or it 

ma v^ge^a^^ototex— ^g^^je^^m , such as a web page URL (e.g. 

http ://www • si/fename . com/pa'gename . html) or a book or magazine article (e.g. Business 
Week, Jan. 1, 1999, p. 100) . Date Item Description Provided 510 stores the date on 
which the data in Item 508 was supplied by the seller. Date Item Provided 512 
stores the date on which the item was provided by the seller. For items which are 
information, this date will usually be the same as Date Item Description Provided 
510. For goods and services, this date might differ from Date Item Description 
Provided 510. Payment Amount 514 stores the amount that the buyer decides to pay 
for the item. Payment Date 516 stores the date on which the buyer assigns the 
payment amount for this item. Note that the date the payment is actually made from 
the buyer to the system operator to pay for this item doesn't need to be stored in 
this table, since it can always be found in the Buyer Payments To S ys t^ero^daTab'ase^ 
1000 (FIG. 10) . 
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Detailed Description Text (32) : 

Buyer Payments. -To. System . I D,- 518.,* s.to.res^t-he, numerical ID^.f rom v-Buyer- Payments. /To o .^.^ w 
System database 1000 corresponding to the payment from the buyer to the system 
operator which includes the payment for this item. There will usually be a one-to- 
many correspondence between a buyer's payments to the system operator and a buyer's 
payment assignments for specific items; in other words, a buyer will make one large 
payment to the system operator in order to cover the payments for several items at 
once- System Payments To Sellers ID 520 stores the numerical ID from System 
Payments To Sellers database 900 corresponding to the payment from the system 
operator. to the seller which pays for this amount. There will usually be a one-to- 
many correspondence between the system operator's payments to a seller and the 
seller's assigned payments from various buyers for various items; in. other words, a 
seller will receive one large payment from the system for a lot of items he/she 
provided. Status 522 stores the current status of this item (e.g. 'delivered but 
price not yet set'). Correspondence 524 stores communications back and forth, if 
any, between the buyer and seller regarding this item. 

Detailed Description Text (33) : 

Referring to FIG. 5b, in various embodiments, some information is stored in this 
database in addition to that shown in FIG. 5a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. Sa and FIG. 5b, 
the numbers refer to the same elements in both): Item Type 550 stores information 
on what type of item the item is. Types can vary in various embodiments. For 
example, in one embodiment Item Type 550 stores either 'information', 'goods', or 
'services'. In another embodiment, Item Type 550 could store more specific 
information, such as ' information: stock research : earnings prediction'. In a 
preferred embodiment, the system operator has the ability to change item types that 
he/she feels have been set incorrectly. Conditions 552 stores information on any 
specific conditions on the sale of the item, imposed by the seller; for example, 
how delivery will occur. Suggested Payment 554 stores a suggested payment amount 
that the seller can optionally provide for the buyer, which the buyer is free to 
consider or disregard. Request ID 556 is Item Request ID 802 (FIG. 8) for those 
items which sellers offered in response to a buyer's item request; otherwise it is 
null. 

Detailed Description Text (34): 

Referring to FIG. 6a, Sellers database 600 maintains data on individuals, companies 
and other entities which are or want to be sellers, such as Seller ID 602, Company 
Name 604, Web Site URL 606, First Name 608, Last Name 610, User Name 612, Password 
614, Phone 616, Email 618, Address 620, City/State 622, Zip 624, Country 626, 
Date/Time Joined 627, Balance 628, Preferences 630, and Comments 632. In a 
preferred embodiment, Sellers database 600 has one record (row) for each seller: 
Seller ID 602 is a unique identifier for the seller. Company Name 604 stores the 
name of the company if the seller is a company, otherwise it is blank. Web Site URL 
606 is the URL for the home page of the company's web site if the company has a web 
site, otherwise it is blank. First Name 608 stores the first name of the seller, or 
the first name of the primary contact person if the seller is a company: Last Name 
610 stores the last name of the seller, or the last name of the primary contact 
person if the seller is a company. User Name 612 stores the name by which the 
seller will be identified throughout the system. Password 614 stores the password 
which the seller will use to gain access to areas which are password-protected and 
areas which require authenticated identification. Phone 616 stores the phone number 
of the seller. Email 618 stores the email address of the seller. Address 620 stores 
the postal address of the seller (e.g. 123 Main Street). City/State 622 stores the 
city and state of the seller. Zip 624 stores the zip code of the seller. Country 
626 stores the country of the seller. Date/Time Joined 627 stores the date and time 
when the seller joined the system. Balance 628 stores the current balance of the 
seller, which is owed to him/her by the system operator. Preferences 630 stores the 
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seller's preferences about the various settings within the system which the seller 
has full or partial control over, such as the format in which various information 
is . display ed. -Comments -;632 -stores- any..comments^that--the . system* opexator ^enters .> 
about the seller. 

Detailed Description Text (35) : 

In various embodiments, some of this information is stored on seller's interface 
400, such as through a text file, database file or a "cookies" file. 

Detailed Description Text (36) : 

Referring to FIG. 6b, in various embodiments, some information is stored in this 
database in. addition to that shown in FIG. 6a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. 6a and FIG. 6b, 
the numbers refer to the same elements in both) : Birth Date 650 stores information 
on when the person was born, to be used to confirm that the seller is of legal age, 
not a minor. Gender 652 stores information about whether the seller (or the primary 
contact person if the seller is a company) is male or female, demographic 
information that might be of use to some buyers. Occupation 654 stores information 
about what occupation the seller is (or what type of company the seller is, if the 
seller is a company) , demographic information that might be of use to some buyers. 
Education Level 656 stores information about what education level the seller 
achieved (if the seller is an individual), demographic information that might be of 
use to some buyers. Household Income 658 stores information about the approximate 
annual household income of the seller (if the seller is an individual), demographic 
information that might be of use to some buyers. Areas of Expertise 660 stores 
information about the specific areas of expertise of the seller and/or types of 
items the seller has or is likely to be able to provide, information that might be 
of use to some buyers. In one embodiment, there is an additional table to store 
detailed information about seller expertise or specific types of items that a 
seller has for sale. The expertise or items could be classified according to 
type/category. In one optional feature of this embodiment, there are several levels 
of expertise for a given skill or area (i.e. expert, significant experience, some 
experience, etc.). In another optional feature of this embodiment, a seller has to 
pass a test or meet certain other qualifications in order to qualify as an expert. 
In another optional feature of this embodiment, penalties are imposed for sellers 
who claimed to be experts in a specific area but later turned out not to be, either 
by not having the claimed specific qualifications or by not having a sufficiently 
high average payment for transactions of the type in which the seller claimed to be 
an expert. Want Newsletter 662 stores information about whether the seller wants to 
receive periodic emails from the system operator about general system news and 
related information. Why Joined 664 stores information about why the seller joined 
the system, which might be useful to the system operator for marketing purposes. 
How Found 666 stores information about how the seller discovered the system, which 
might be useful to the system operator for marketing purposes. Other Contact Info 
668 stores information about other ways to contact the seller, such as pager 
number, voicemail address, and fax number. Credit Card Info 670 stores the seller's 
credit card information, for the purposes of identification or for embodiments 
which allow sellers to receive payments by credit card. Bank Account Info 671 
stores the seller's bank account information, for the purposes of identification or 
for embodiments which allow sellers to receive payments directly to their bank 
accounts. Social Security Number 672 stores the seller's social security number if 
the seller is an individual, or a company's Federal Employer Identification Number 
if the seller is a company, for the purposes of identification. Payment Preference 
674 lets the seller indicate how he/she prefers to receive payment for items, for 
embodiments which allow multiple payment methods. Anonymous 676 lets the seller 
choose to remain anonymous, identified only by a consistent ID rather than his/her 
name or company name. For numerous privacy and competitive reasons, sellers might 
prefer not to have their identities revealed to the general public when engaging in 
commercial transactions. 
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Detailed Description Text (37) : 

.Referring^ to- FIG.,u7a, 3uve cs .^dat abas e .700. maintai ns^dat a . on^indiv-iduals-,- companies^- 
and other entities which are or want to be buyers, such as Buyer ID 702, Company 
Name 704, tfeb Site URL 706, First Name 708, Last Name 710, User Name 712, Password 
714, Phone 716, Email 718, Address 720, City/State 722, Zip 724, Country 726, 
Date/Time Joined 727, Balance 728, Preferences 730, Comments 732, and Seller ID 
734. In a preferred embodiment, Buyers database 700 has one record (row) for each 
buyer. Buyer ID 702 is a unique identifier for the buyer. Company Name 704 stores 
the name of the company if the buyer is a company, otherwise it is blank. Web Site 
URL 706 is the URL for the home page of the company's web site if the company has a 
web site, otherwise it is blank. First Name 708 stores the first name of the buyer, 
or the first name of the primary contact person if the buyer is a company. Last 
Name 710 stores the last name of the buyer, or the last name of the primary contact 
person if the buyer is a company. User Name 712 stores the name by which the buyer 
will be identified throughout the system. Password 714 stores the password which 
the buyer will use to gain access to areas which are password-protected and areas 
which require authenticated identification. Phone 716 stores the phone number of 
the buyer. Email 718 stores the email address of the buyer. Address 720 stores the 
address of the buyer (e.g. 123 Main Street). City/State 722 stores the city and 
state of the buyer. Zip 724 stores the zip code of the buyer. Country 726 stores 
the country of the buyer. Date/Time Joined 727 stores the date and time when the 
buyer joined the system. Balance 728 stores the current balance of the buyer, if 
the total payments the buyer has made to the system operator exceed the amounts the 
buyer has paid for items he/she purchased. Preferences 730 stores the buyer's 
preferences about the various settings within the system which the buyer has full 
or partial control over, such as the format in which various information is 
displayed. Comments 732 stores any comments that the system operator enters about 
the buyer. Seller ID 734 stores the same number as the Seller ID 602 if the buyer 
also happens to be a seller, which is permitted in a preferred embodiment. ^ 

Detailed Description Text (38): 

In various embodiments, some of this information is stored on buyer's interface 
300, such as through a text file, database file or a "cookies" file. 

Detailed Description Text (39): 

Referring to FIG. 7b, in various embodiments, some information is stored in this 
database in addition to that shown in FIG. 7a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. 7a and FIG. 7b, 
the numbers refer to the same elements in both): Cutoff Percentile 750 stores the 
minimum percentile cutoff of eligible sellers for this buyer. This is the value 
that the buyer has entered, indicating the lowest acceptable percentile of sellers, 
in terms of their average payments received for items. In a preferred embodiment, 
sellers below this threshold are not able to provide items to the buyer. Birth Date 
752 stores information on when the person was born, to be used to confirm that the 
buyer is of legal age, not a minor. Gender 754 stores information about whether the 
buyer (or the primary contact person if the buyer is a company) is male or female, 
demographic information that might be of use to some sellers. Occupation 756 stores 
information about what occupation the buyer is (or what type of company the buyer 
is, if the buyer is a company), demographic information that might be of use to 
some sellers. Education Level 758 stores information about what education level the 
buyer achieved (if the buyer is an individual) , demographic information that might 
be of use to some sellers. Household Income 760 stores information about the 
approximate annual household income of the buyer (if the buyer is an individual) , 
demographic information that might be of use to some sellers. Want Newsletter 762 
stores information about whether the buyer wants to receive periodic emails from 
the system operator about general system news and related information. Why Joined 
764 stores information about why the buyer joined the system, which might be useful 
for marketing purposes. How Found 766 stores information about how the buyer 
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discovered the system, which might be useful for marketing purposes. Other Contact 
Info 768 stores information about other ways to contact the buyer, such as pager 
number, voicemai,!, -address, andx.f ax .number. ..Credit Card Info JLIO ..store s^the^buyer s . *. ^ 
credit card information, for the purposes of identification or for embodiments 
which allow buyers to make payments by credit card. Bank Account Info 771 stores 
the buyer's bank account information, for the purposes of identification or for 
embodiments which allow buyers to make payments directly from their bank accounts. 
Social Security Number 772 stores the buyer's social security number if the buyer 
is an individual, or a company's Federal Employer Identification Number if the 
buyer is a company, for the purposes of identification. Payment Preference 774 lets 
the buyer indicate how he/she prefers to make payments for items, for embodiments 
which allow multiple payment methods. Anonymous 776 lets the buyer choose to remain 
anonymous, identified only by a consistent ID rather than his/her name or company 
name. For numerous privacy and competitive reasons, buyers often prefer not to have 
their identities revealed to the general public when engaging in commercial 
transactions. 

Detailed Description Text (40): 

In some embodiments, such as those in which a significant proportion of 
participants sometimes act as a buyers and sometimes as sellers, tne ^^^^J s 
database 600 and B uvex a, . database 700 arc rep lac ed by a__ s in gle database. 

Detailed Description Text (41): 

Referring to FIG. 8, Buyer Item Requests database 800 maintains data on requests 
that buyers make for items and types of items (in those embodiments which allow for 
such requests), such as Item Request ID 802, Buyer ID 804, Date/Time 806, 
Description 808, and Status 810. One example of an item request would be the^ answer 
to a specific question: in this case, the item that the buyer is requesting is the 
answer to the question. In a preferred embodiment, Buyer Item Requests database 800 
has one record (row) for each item or type of item requested by each buyer. Item 
Request ID 802 is a unique identifier for the item request. Buyer ID 804 is the 
number corresponding to Buyer ID 702 for the buyer making the item request. 
Date/Time 806 stores the date and time at which the item request was made. 
Description 808 stores a description of the requested item, type of item, or area 
of expertise. Status 810 stores the current status of the item request. For 
example, the status could be 'open* or % closed', and if it's closed then Status 810 
also indicates the value for Item ID 502 corresponding to the item which fulfilled 
the request. 

Detailed Description Text (42): 

In some embodiments, Buyer Item Requests database 800 is not used and the 
information it includes is instead included in Buyers database 700. 

Detailed Description Text (43): 

Referring to FIG. 9, System Payments To Sellers database 900 maintains data on 
payments made by the system operator to sellers, such as System Payment ID 902, 
Seller ID 904, Date/Time 906, and Payment 908. In a preferred embodiment, System 
Payments to Sellers database 900 has one record (row) for each payment the system 
operator makes to any seller. System Payment ID 902 is a unique identifier for each 
system payment. Seller. ID 904 stores the value in Seller ID 602 for the seller who 
received or will receive the payment. Date/Time 906 stores the date and time at 
which the payment is made from the system operator to the seller. Payment 908 
stores the amount of the payment. 

Detailed Description Text (44): 

Referring to FIG. 10, Buyer Payments To System database 1000 maintains data on 
payments made by buyers to the system operator, such as Buyer Payment ID 1002, 
Buyer ID 1004, Date/Time 1006, and Payment 1008. In a preferred embodiment, Buyer 
Payments To System database 1000 has one record (row) for each payment a buyer 
makes to the system operator. Buyer Payment ID 1002 is a unique identifier for each 
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buyer payment. Buyer ID 1004 stores the value in Buyer ID 702 for the buyer who 
made or will make the payment. Date/Time 1006 stores the date and time at which the 
^payment-, is^made, f rom^the^buyer^to^the - system operator,* P.ayment, lOOS-.stones-.thew,.^.,;^. 
amount of the payment. 

Detailed Description Text (45) : 

Referring to FIG. 11, Kicked Out database 1100 maintains data on which participants 
have been kicked out of the system, such as for rule violations, and should not be 
allowed to rejoin (in those embodiments which track such information), such as 
Buyer Or Seller 1102, Buyer Or Seller ID 1104, Date/Time 1106, and Comments 1108. 
In a preferred embodiment, Kicked Out database 1100 has one record (row) for each 
buyer or seller who has been kicked out of the system. Buyer Or Seller 1102 stores 
information on whether the participant was a buyer, a seller, or both. Buyer Or 
Seller ID 1104 stores the value in Seller ID 602 for this participant if he/she was 
a seller, or the value in Buyer ID 702 for this participant if he/she was a buyer 
or both a buyer and a seller. Date and Time 1106 stores the date and time when the 
participant was kicked out of the system. Comments 1108 stores details about why 
the participant was kicked out of the system, and is entered by the system 
operator. 

Detailed Description Text (46) : 

In some embodiments, Kicked Out database 1100 is not used and the information it 
includes is instead included in Sellers database 600 and Buyers database 700. In a 
preferred embodiment, poorly performing participants (based on a variety of 
criteria, such as low average payments for buyers or sellers, or a significant 
number of late or missed payments for buyers) and rule violators can be removed 
from the system and/or other sanctions can be imposed. 

Detailed Description Text (48): 

Referring now to FIG. 12, there is described one embodiment of the flow of 
information and payments related to a given transaction in the system. Before a 
transaction can occur between a buyer and a seller, each must join the system (1202 
and 1204 respectively) and enter some profile information (1206 and 1208 
respectively). In a preferred embodiment, this is done through Buyer Registration 
form 1400 and Seller Registration form 2000. In a preferred embodiment, the 
participant can jodjianc^nte^ at the same time, or can 

^#Effj?RS?^n^ - I n another embodiment, both 

must be entered at t^ atifg »eg§^^feg^S^3 



Detailed Description Text (49): 

The steps involved in a single transaction in a preferred embodiment are 
illustrated in Transaction Process 1210. In a preferred embodiment, a transaction 
can begin in two different ways: either a buyer requests a specific item from a 
seller using Buyer Item Request form 1700, probably after searching using Buyer 
^e?aiBch,e.s m F o r^S ; aM:ejri3J^gxm 1600, or a seller provides an item or a description of an 
stein - using '^TeTprovides Item form 2300 (1212 and 1213 respectively) . In the 
former case (1212), the seller then either provides the item or a description of 
the item using Seller Provides Item form 2300, or provides a different item or a 
description of a different item using Seller Provides Item form 2300, or chooses 
not to provide the item or description in which case the transaction ends (1213, 
1214, and 1215 respectively). These actions of the buyer and seller are stored in 
Items database 500. 

Detailed Description Text (55) : 

Referring to FIG. 14, there is described one embodiment of the Buyer Registration 
form, which enables individuals, companies and other entities to register to 
participate as buyers in the system. The form includes Company Name, Site Name (for 
those participants which have web sites), URL (for those participants which have 
web sites), Category (which lets them indicate which category or categories they 
might want to express an interest in being a buyer of items for) , Date/Time (which 
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is filled in automatically), Name 1410, Password 1412, Phone Number, Email Address, 
Postal Mail Address, Initial Payment, Preferred Payment Method 1413, and Additional 
-Faymen-t^Info™ 

registering and using the system, he/she understands that transactions he/she 
enters into form legally binding contracts. When a buyer registers, the system 
compares Kicked Out database 1100 with Sellers database 600 and Buyers database 700 
to see if a buyer or seller with the same first name and last name, company name, 
address, credit card number, and/or Social Security number has already been kicked 
out of the system. If the buyer has not already been kicked out of the system and 
the buyer meets any other requirements, the buyer is accepted into the system and 
the information he/she entered is placed in Buyers database 700. In a preferred 
embodiment, this form also enables an existing buyer to update his/her information. 
In one embodiment, this form also includes an Item Request link 1417, which takes 
him/her to Buyer Item Request form 1700, enabling him/her to make item requests. 

Detailed Description Text (58): 

Referring to FIG. 15, there is described one embodiment of Buyer Login form 1500, 
through which buyers enter their Name (1410 in FIG. 14) and Password (1412 in FIG. 
14) in order to log in to the system (1502). The Buyers database is checked to 
confirm that the Name and Password that have been entered correspond to a 
registered buyer. If login is successful, they can perform a variety of activities 
such as: click on B u yer Searches For Sel lers ^ link 1504 to go to Buyer Searches For 
Sellers form 1600; ^S^^^^^^^^^^eq^st link 1506 to go to Buyer Item 
Request form 1700; click on Buyer Views Items link 1508 to go to Buyer Views Items 
page 1800; and click on Buyer Account Information link 1510 to go to Buyer Account 
Information page 1900. The buyer can also click on Buyer Specifies Acceptable 
Sellers 1512 to go to Buyer Specifies Acceptable Sellers form 3200 to specify, 
characteristics of sellers that the buyer is willing to accept items from. In. one 
embodiment, the buyer can also click on Top Listings link 1514 to go to Top r 
Listings page 2800. Update Registration Information 1516 enables the buyer to 
change some of the registration information he/she entered upon initially joining 
the system. In some embodiments, various other information which would be of use to 
buyers is included on this page. 

Detailed Description Text (59) : 

In one embodiment, anyone is allowed to participate as a buyer or a seller. In 
another embodiment, some or all participants must meet certain requirements, such 
as filling out an application, taking a test, passing a credit check, or meeting 
certain demographic criteria or other requirements. In one embodiment, the system 
has certification testing for sellers and/or buyers. In one optional feature of 
such an embodiment, certification testing is a requirement for joining; in another, 
it is not a requirement but the pass/fail grade information is included in the 
participant's profile and some or all other participants can see it, and in one 
optional feature of such an embodiment, some or all other participants can choose 
to transact only with those who passed the test. 

Detailed Description Text (60) : . 

Referring to FIG. 16, there is described one embodiment of Buyer Searches For 
Sellers form 1600, which enables buyers to search the database for specific types 
of sellers and/or items. FIG. 16 shows some <e^gSmpiqe's^ ^§^lcli e s this form might 

allow, such as : ^^^^S^ ^^^^^^T^ 60 2 ; 3earchin 4_^ ffl^jPf 1604 ( which would 
show informationf EE fo*o l 5ST^ thx^^^ ^^^^n^ ^ area of expertise 

1606; searching by occupation 1608; searching by specific text 1610; 
searching/screening by seller's average payment 1612; searching/ screening by 
seller's number of completed transactions 1614; and searching by comments other 
participants have made about a seller, for embodiments which include this feature 
(1615) . Multiple search criteria can be specified, enabling buyers to search for 
very specific types of sellers and/or items, for example: displaying all items that 
are services from sellers whose occupation is lawyer and whose average payment is 
greater than §5 and whose number of completed transactions is at least 20. Such 
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queries can be written with standard SQL to return records from the various 
databases in Data Storage Device 220. The results of the search (1616) are 
displayed,' „ei.the x^on^fche* same pag.e • or,, on^a^subsequen t >.page , u in ^such^a^way^that^t he - * ,. 
buyer is able to initiate a transaction by clicking on one of them and going to 
Buyer Item Request form 1700 (for those embodiments which include this form) and 
making an item request. 

Detailed Description Text (61) : 

In a preferred embodiment, some subset of the information about participating 
sellers and buyers is available to sellers, some subset of the information about 
participating sellers and buyers is available to buyers (primarily through Buyer 
Searches For Sellers form 1600 in FIG. 16, Seller Searches For Buyers form 2200 in 
FIG. 22, Top Listings page 2800 in FIG. 28, and Participant Directory 2900 in FIG. 
29), and some information is not made available to anyone other than the system 
operator. In one embodiment, contact information such as phone number, email 
address, and possibly the participant's name are not made public, either for all 
participants (this is designed to enable the system to discourage 
disintermediation, in which the participants bypass the system and transact 
business directly) or for those who want it (some, participants might want 
anonymity) . In some embodiments, a participant has partial control over what 
information about that participant is available to others through the system. For 
example, if anonymity is desired, a participant's ID rather than the person's or 
company's name might be displayed. 

Detailed Description Text (62) : 

Some information regarding a given buyer's or seller's earlier transactions can be 
viewed by buyers and sellers (and sometimes even visitors who aren't yet 
participants), in order to enable other buyers and sellers to better determine 
whether they wish to enter into transactions with the buyer or seller. Such data 
may include (in some embodiments) but not be limited to: number of transactions; 
average payment (in a preferred embodiment, mean payment is used; in another 
embodiment, median payment or some other calculated average is used) ; timeliness of 
payments (e.g. percent assigned on time, percent paid on time, percent ever paid); 
and comments and/or ratings from those who have transacted with that buyer/seller. 
In one embodiment, when fee a cch#nia^t'hie^ida^ateg s:ej jf o r potential transactions, buyers 
and/or sellers are able €8*s*Ereen by This type of criteria. 

Detailed Description Text (66) : 

Referring to FIG. 17, there is described Buyer Item Request form 1700, which exists 
in some embodiments. It enables buyers to specify items they would like to buy. 
They can indicate specific items (1702) or types of items (1704) . They can also 
indicate what types of sellers they are interested in buying such items from: a 
specific seller or list of specific sellers (1706) ; a type or types of sellers 
(1708); or other requi red seller cr U:.exia ( 1710) . In some embodiments, there is one 
standard form for buyers to maie^fe^m^re^^sts , but there are also a variety of 
other item request templates (1712) for qms^ j figm W^^B^ e ^ ^ e ^^^^} a x ^^P^£Szf > f 
it e mj ep ^ e s ts^ such as: a. web site testing and feedback b. document review (for 
grammar, professionalism, legal, etc.) c. specific question answering, help, advice 
d. request for resources (books, sites, etc.) for a specific subject or question e. 
research request, fact checking, survey completion f-. consultant needed, contract 
work g. recruiting employees h. new product names i. any type of activity that is 
companies often outsource j. product wanted to. purchase k. anything that people 
often have trouble finding (i.e. lead generation, affiliate programs, and big- 
ticket items like houses, apartments, or cars) 1. specific requests: a buyer can 
make a request for item suggestions, one or more of which will be selected (in one 
embodiment, a buyer can indicate that he/she might be willing to pay a certain 
amount or an approximate amount for the best response they receive (ex. for new 
product name, an ad campaign idea, a slogan, a jingle, etc.), or he/she can split 
that between sellers, whatever way the buyer wants. The buyer can also make a 
request without an indication of expected payment.) 
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Detailed Description Text (67): 
...Each-., of : the.^above- .types*i-o£vvspeci-£ ic, request, •forms^has* .some * requi red . f i elds,- and/ or^w^ 
some optional fields, which one skilled in the art could create without difficulty. 
The entered information is stored in Buyer Item Requests database 800, or. in some 
embodiments cpjjlgl be stored_in a separate database^ In one embodiment, sellers who 
meet the requ^e^^r^e^rare l S^rve^? l n , B* > ?^^^e^u^lx, either by being alerted or by 
seeing it o B^ejli!j!l»erfwS^^ In one embodiment, a buyer can 

optionally prov^e^gu^o^^^^a^BtrWPirar payment amount they might be willing to pay 
for the desired item (1714). 

Detailed Description Text (71) : 

In a preferred embodiment, the buyer has a predetermined amount of time after the 
information is entered in which to assign the payment (if any) , and a predetermined 
amount of time (either after the information is entered or after the payment is 
assigned) in which to pay (in the non-prepayment embodiment) . In a preferred 
embodiment, for transactions in which the buyer and seller are corresponding about 
the item, the clock 'resets to zero' (i.e. the buyer again has the full amount of 
time) when the seller sends a message; in another embodiment, the clock doesn't 
reset; in another embodiment, the clock is only "ticking" when the seller is 
waiting for a message from the buyer and not the reverse (similar to the way a 
chess clock functions) . In one embodiment, the notification that the buyer receives 
about the information also mentions that this payment clock has begun, and the 
system operator can give the buyer another notification just before the time 
expires. In embodiments requiring prepayment, there obviously are not any payments 
made late (although some payment amounts might still be assigned late) . In such 
cases, each buyer has his/her own billing date, probably once per month (or all 
buyers have the same billing date, probably once per month) . All payments assigned 
by that date will be billed in a single bill on that date. The buyer will have a 
predetermined number days to pay the bill. If they don f t pay on time, the payments 
for all those items will be set to zero, but jff the buyer later pays, those items 
will be set to the correct numbers (the database will differentiate between an 
assigned zero payment and a late-payment zoto payment). In one embodiment, sellers 
are paid by the system operator on a regular basis, provided they are owed at least 
some minimum amount. In one embodiment, buyers have to pay an additional fee for 
late payments. In one embodiment, payments can be non-cash, such as products, 
services, product discounts, or system credits. 

Detailed Description Text (74): 

If the seller later replies to the buyer's request for additional information by 
entering it in 2416 on FIG. 24, that information will appear in 1816. In one 
embodiment, a buyer has the ability to return to this form and change payment 
amounts that he/she previously assigned, up to the time the payment is made; in 
another embodiment, a buyer cannot change a payment amount once it is assigned; in 
another embodiment, a buyer can raise a payment amount, but cannot lower it, once 
it he/she initially sets it. In one embodiment, if the item corresponds to an Item 
Request that the buyer has made, the buyer can close the item request (1818) so 
that no other sellers provide items in response to the item request. The data 
entered on this form is written to, and the data displayed on this form is taken 
from, Items database 500. If the buyer decides to send a note to the seller, 
information about the seller, including his/her contact information, is read from 
Sellers database 600. In one embodiment, the page includes for each communication 
between buyer and seller any relevant reference IDs (possibly linked) to earlier 
communications, for that item and/or for all previous interactions between that 
buyer and that seller. In one embodiment, a buyer has the option (but not the 
obligation) to assign a payment amount and/or make payment before receipt of the 
item. For example, a buyer might receive a description of an item (such as a good 
or service) from a seller, and decide to assign a payment amount and/or make 
payment before receipt of the actual item (in other words, the buyer can use the 
pay-after- receipt technique of the present invention for some items and the more 
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conventional pay-before- receipt technique for others). 



. D e t ai J.- ed .iDescr jjp.t-i o n. tT e x .tx ^CX?*) c: >i < ^.t. * *ux ; . - ^ . < ./.i-u^-ua^ , • a : ■ . ■ * ^ . r w ^ w ■ . ^ * ^ . i^cc • i» 
Referring to FIG. 19, there is described one embodiment of Buyer Account 
Information page 1900, which enables a buyer to check his/her account information, 
including Name, current Date/Time, and Current Account Balance. The page also 
displays various account metrics, such as the buyer's average payment, number of 
items bought, average time to pay, and percentage of payments made on time. The 
page also displays a list of payments the buyer made and the dates on which those 
payments were made. The data displayed on this page are taken from Buyer Payments 
To Syste m database 1000 and Items database 500. The page also lets buyers make 
payments to cover their item purchases (1910) . Payments are made by buyers to the 
system operator. There will usually be a one-to-many correspondence between a 
buyer's payments to the system operator and a buyer's payment assignments for 
specific items; in other words, a buyer will make one large payment to the system 
operator in order to cover the payments for a lot of items all at once. In a 
preferred embodiment, payments by buyers to the system operator can be made by 
check and/or credit card. In another embodiment, a micropayment system is an option 
for the buyer. In one embodiment, a buyer must prepay the system operator an amount 
which will be used to pay for subsequent items through a declining balance method. 
In another embodiment, a buyer will not have to prepay but will have to pay the 
system operator at regular intervals or once a certain balance due has been 
reached. In one optional feature of those embodiments which allow but don't require 
buyer prepayment, sellers have access to information about whether a given buyer 
has a positive balance in his/her account, i.e. whether the buyer will be paying 
immediately. This would encourage buyers to keep a positive balance, since sellers 
would be more inclined to provide items to buyers for whom payment from the buyer 
to the system operator would occur immediately. 

Detailed Description Text (80): 

Skipping ahead to FIG. 32, there is described Buyer Specifies Acceptable Sellers 
form 3200, which exists in some embodiments. It enables buyers to specify that only 
certain sellers are able to provide items to him/her. The criteria the buyer has to 
choose from can include the following: accept all sellers (3202) ; accept those in 
certain areas of expertise and not others, perhaps by choosing Yes or No from a 
scrolling list of all areas of expertise (3204); accept those in certain 
occupations, perhaps by choosing Yes or No from a scrolling list of all occupations 
(3206) ; accept those who have an average payment of at least a certain amount, or 
an average payment of at least a certain percentile of all sellers (3208); accept 
those who have completed at least a certain number of transactions and/or at most a 
certain number of transactions (3210) . Multiple search cri t epLa^^an be specified, 
enabling buyers to be very specific abciuT wn'ich'VeYie'rs "they are willing to accept 
items from. Such queries can be written with standard SQL to return records from 
the various databases in Data Storage Device 220. 

Detailed Description Text (81) : 

Referring to FIG. 20, there is described one embodiment of Seller Registration form 
2000, which enables individuals, companies and other entities to register to 
participate as sellers in the system. The form includes Company Name, Site Name 
(for those participants which have web sites), URL (for those participants which 
have web'sites), Date/Time (which is filled in automatically), Name 2010, Password 
2012, Phone Number, Email Address, Postal Mail Address, Occupation, Education 
Level, Areas of Expertise (site design, graphics, database , programming, marketing, 
email newsletters, tax, law, finance, or just about any other area of expertise), 
Preferred Payment Method 2013 (for those embodiments that allow more than one 
payment method), and Additional Payment Info 2015. In a preferred embodiment, the 
buyer acknowledges that by registering and using the system, he/she understands 
that transactions he/she enters into form legally binding contracts. 

Detailed Description Text (82): 
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Vhen a seller registers, the system compares Kicked Out database 1100 with Sellers 
database 600 and Buyers database 700 to see if a buyer or seller with the same 
. ,i , : f i rst name and-J.as<t-- name , *■ company^ name*,- -add res s.y^c redi t ca rd- numbe r , **and/o c * Social.** 
Security number has already been kicked out of the system- If the seller has not 
already been kicked out of the system and the seller meets any other requirements, 
the seller is accepted into the system and the information he/she entered is placed 
in Sellers database 600. In a preferred embodiment, this form also enables an 
existing seller to update his/her information. In one embodiment, this form also 
includes a Provide Items link 2023, which takes them to Seller Provides Item form 
2300, enabling them to provide items right away. 

Detailed Description Text (85) : 

Each of the above types of "items-available" template forms has some required 
fields and/or some optional fields and/or a place where sellers can add fields of 
their own. Each seller can fill in whichever ones are appropriate. The information 
entered could be stored as a separate table in Items database 500, Sellers database 
600, or another database . 

Detailed Description Text (86) : 

Referring to FIG. 21, there is described one embodiment of Seller Login form 2100, 
through which sellers enter their Name (2010 in FIG. 20) and Password (2012 in FIG. 
20) in order to log in to the system (2102). The Sellers database is checked to 
confirm that the Name and Password that have been entered correspond to a 
registered seller. If login is successful, they can perform a variety of activities 
such as: click on Seller Searches For Bu yers l ink 21(M to go to Seller Searches For 
Buyers form 2200; click on Seller P reveres J. rem j!ink 2106 to go to Seller Provides 
Item form 2300; click on SellerViews^^ems^^nJc^lO^ to go to Seller Views Items 
page 2400; and click on Seller Account Information link 2110 to go to Seller 
Account Information page 2500. In one embodiment, the seller can also click on Top 
Listings link 2112 to go to Top Listings page 2800. Update Registration Information 
2114 enables the seller to change some of the registration information he/she 
entered upon initially joining the system. In some embodiments, various other 
information which would be of use to sellers is included on this page. 

Detailed Description Text (87) : 

Referring to FIG. 22, there is described one embodiment of Seller Searches For 
Buyers form 2200, which enables sellers to search the database for specific types 
of buyers and/or items. FIG. 22 shows some examples of searches this form might 
allow, such as : searching all buyers 2202; searching by open item requests 2204 
(which would show only those item requests which haven't yet been satisfactorily 
fulfilled as specified by the buyer using Close Item Request 1818 in FIG. 18); 
searching by category of buyer 2206; searching by specific text 2208; 
searching/ screening by buyer's average payment 2210; searching/ screening by buyer's 
number of completed transactions 2212; searching by buyer's percentage of on-time 
payments 2214; and searching by comments other participants have made about a 
buyer, for embodiments which include this feature (2215) . Multj^^^searchcrit e ria 
can be specified, enabling sellers to search for very specir^ptype^^5r^Buy^r^* B ^ Brasi * 
and/or items, for example: displaying all items that include the word 
* nanotechnology* and are wanted by buyers whose average payment is greater than $3 
and who have made at least 8 0% of their payments on time. Such queries can be 
written with standard SQL to return records from the various databases in Data 
Storage Device 220. The search results 2216 would be displayed, either on the 
current page or another page, in such a way that the seller is able to initiate a 
transaction by clicking on one of them and going to Seller Provides Item form 2300 
to provide an item. In one embodiment, search results 22 16 include information 
about what items other sellers have supplied in an attempt to satisfy the item 
request, and what the results were, so that they might build on these efforts and 
better learn what the buyer is looking for, rather than duplicating prior efforts. 
In a preferred embodiment, searching by open item requests 2204 will show only 
those item requests which the seller is capable of responding to, as determined by 



http://westbrs:9000/^ Message-.. 2/23/05 



whether the seller meets the buyer's cutoff percentile requirement and any other 
specified requirements. In another embodiment, the seller would be able to view, 
^but-^not -to provide ^iitems^for.,^ it enu requests . f Qr^which A ,he/:she^does -not- meet-uthe*-, 
requirements. 

Detailed Description Text (88): 

Referring to FIG. 23, there is described one embodiment of Seller Provides Item 
form 2300. This form enables a seller to provide items to buyers through the 
system. In each transaction, the seller provides the item to one or more buyers, 
with the understanding that there is no guarantee of any specific compensation. In 
a preferred embodiment, only those buyers who are interested in receiving items 
from a seller who fits the description of this seller will appear on this form (as 
those buyers specified on Buyer Specifies Acceptable Sellers form 3200) . For 
example, if a buyer specifies that he/she only wants items from sellers whose 
average payment is in the top 20% of all sellers, then sellers who don't meet this 
requirement are not able to specify such buyers on this form. The seller enters the 
actual item (if the item is information) or a description of the item (2302) , and 
specifies which of the available buyers the seller wants to sell the item to 
(2304). The item's description is entered into Items database 500. The seller then 
provides the specified item to the buyer. This could involve the delivery of 
physical goods as well as digital goods. 

Detailed Description Text (91): 

In one embodiment, the seller may list items that he/she doesn't necessarily 
currently have; the offer is not binding, and in some cases will just be a 
description of what he/she might be able to provide. This can be done in order to 
enable buyers to indicate an interest in the item. In one embodiment, a seller can 
provide descriptive information about an item or type of item and wait for a t 
response from a buyer (for an indication of interest, estimation of what range of 
prices they might be willing to pay, etc.) before actually providing the item. In 
such embodiments, a buyer can view such information through^&gjej^^^^^^s^^ar~E^ 
^^^gMg^lP cm 1600. 

Detailed Description Text (92): 

Referring to FIG. 24, there is described one embodiment of Seller Views Items page 
2400, which enables a seller to view all the items which that seller has provided 
to buyers by filling out Seller Provides Item form 2300. For each such item,, the 
page displays: the actual item if the item is information (2402) or a description 
of the item (2404); the buyer (2406); the date/time at which the seller provided 
the item (2408); the payment amount if it has been set by the buyer (2410); and 
date/time at which the payment amount was set, if the buyer has set it (2412) . This 
page also displays a buyer's request for additional information about an item 
(2414), if the buyer has made such a request in 1814 on Buyer Views Items page 
1800. If the seller replies to the request by entering it in 2416, that information 
will appear in 1816 on Buyer Views Items page 1800. The data entered on this page 
is written to, and the data displayed on this page is taken from, Items database 
500. If the seller decides to send a note to the buyer, information about the 
buyer, including his/her contact information, is read from Buyers database 700. In 
one embodiment, the page includes for each communication between buyer and seller 
any relevant reference IDs (possibly linked) to earlier communications, for that 
item and/or for all previous interactions between that buyer and that seller. 

Detailed Description Text (95) : 

Referring to FIG. 25, there is described one embodiment of Seller Account 
Information page 2500, which enables a seller to check his/her account information, 
including Name, current Date/Time, and Current Account Balance. The page also 
displays various account metrics, such as the seller's number of items sold, 
average payment, average payment for each buyer the seller sold at least one item 
to, and outstanding payments (i.e. payments made by buyers to the system operator 
but not yet received by the seller from the system operator) . The page also 
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displays a list of payments the seller received and the dates on which those 
payments were received. The data displayed on this page are taken from System 
Eavmen:ts-,Xo.': Sellers^ database ,900 *.ancUI- terns . database .^5 0 0 »ua nd ^ can, rb e * r e tr i eve d -from 
the databases with js ^xtdft^ ^^ h^&i^ir&s^ 

Detailed Description Text (103) : 

Referring to FIG. 28, there is described Top Listings page 2800, which exists in 
some embodiments. This displays various rankings of participants, such as: top 
participants, based on some quantitative calculation (2802); buyers who have bought 
the largest number of items in the last X days, where X is some predefined number, 
and overall (2804); sellers who have sold the largest number of items in the last X 
days, and overall (2806); buyers who have the highest average payment (i.e. total 
payments divided by number of items) in the last X days, and overall (2808); 
sellers who have the highest average payment in the last X days, and overall 
(2810) ; buyers who have the highest total payments in the last X days, or overall 
(2812), and sellers who have the highest total payments in the last X days, and 
overall (2814) . The data displayed on this page is taken from Items database 500, 
Sellers database 600, and Buyers database 700, and can be taken from the databases 
using s t a n cjaxd SQL queries. FIG. 28 is an exemplary illustration, and in some 
embodi me n t s i nTcWua^if^^e^T.i s ti ng s such as items which received the highest 
payments, item types which received the highest average payments, and newest buyers 
and sellers to join the system. In one embodiment, the display differs depending on 
whether the participant was a buyer or a seller. This information could be 
collected automatically from the database, or could be collected manually by the 
system operator. This would help educate participants about what types of 
information receive high payments. In one optional feature of this embodiment, 
buyers and/or sellers could specify that they don't want their transaction 
information reveal others in this manner. In one embodiment, the items receiving 
the highest payments in the last X days, and overall, are displayed. In one 
embodiment, a participant can view the top listings out of those which meet 
criteria specified by the participant (for example, top listings by lawyers, or top 
listings by participants in Virginia). 

Detailed Description Text (104) : 

Referring to FIG. 29, there is described Participant Directory 2900, which exists 
in some embodiments. The data displayed on this page is taken from Sellers database 
600 and Buyers database 700, and can be taken from the databases using standard SQL 
queries ■ Different embodiments include different information in this directory; 
FIG. 29 is an exemplary embodiment. In some embodiments, the directory includes a 
hierarchical classification system, which is included on the buyer's and seller's 
registration forms and stored in the database to be queried here. In some 
embodiments a participant can choose not to be listed here, while in other 
embodiments the listing is required. 

Detailed Description Text (107) : 

In one embodiment, in addition to relevant data about a given participant, some 
relevant data is also m ade ,, ^^i | l a kJ^ ^:e ceding specific classesp f items for that 
participant (e.g. not j u sta p a r ti ci pa n t ' s ave rage " pa^rrne rit^JSutt heir average 
payments for e^^^^c^^^s^^^^^^m^they 1 ve had transactions for) . 

Detailed Description Text (109) : 

Referring to FIG. 31, there is described one embodiment of System Operator View 
3100, which can be used by the system operator to get a high-level view of how the 
system is functioning, with details about transaction activity and buyer and seller 
behavior, to enable him/her to better manage the system. In an exemplary 
embodiment, information that can be viewed includes: average payment in a given 
period, average cutoff percentile, total number of buyers and sellers, number of 
new buyers and sellers in a given period, and number of new items provided in a 
given period; graphs of the distribution of buyer-specified cutoff percentiles, the 
distribution of number of items for each buyer, the distribution of number of items 



http://westbrs:9000/^ Messages.. 2/23/05 



for each seller, the distribution of the average payment for each buyer, the 
distribution of the average payment for each seller, the distribution of the total 
.^payment- amounts- J: o&veach^buyer , and-., the- distribution- of M-the. -total^payment^amounts- . . 
for each seller; graphs of the correlation between a buyer's average payment and 
his/her number of items bought per unit time, the correlation between a buyer's 
average payment amount and his/her cutoff percentile, the correlation between a 
buyer's number of items bought per unit time and his/her cutoff percentile, and the 
correlation between a seller's number of items sold per unit time and his/her 
average payment. In a preferred embodiment, the system operator can monitor the 
transactions for rule violators and troublemakers, by using search tools and 
looking for unusual transaction behavior. The data displayed on this view are taken 
from Items database 500, Sellers database 600, and Buyers database 700, and can be 
retrieved from the databases with fgit=ja&m f a1^ 



Detailed Description Text (121) : 

In one embodiment, there can be a plurality of participants on the buyer side or 
the seller side or both (eithej: to act collectively in a single transaction, or in 
a plurality of transactions) . The system would enable participants to publish and 
search 



jlnf ormati onabau^sucluguXt iDle-bu ve r 
JaTTd "would enaK^commun^at^Jns between such~p~a~r 
activities. In the case of a single transaction, 
follows: each buyer decides what he/she wants to 



and 

the 
pay 



m uj^tip i lg^ t g t lle r s ituations, 
D^oordinate^SBe 

payment could be split as 
(if just one seller), or the 
one buyer decides how much each seller gets (if just one buyer); or in the case of 
multiple buyers and sellers, each buyer decides how much to give to each seller. In 
the case of a plurality of transactions, each could be handled exactly as in the 
preferred embodiment. In one optional feature of the plurali ty-of - transactions 
embodiment, sellers would be able to see information that other sellers provided to 
a given buyer, so that the sellers might be able to collectively help the buyer 
better than if the sellers were acting independently. In another embodiment, they 
would not be able to see such information, or they might only be able to see such 
information in some cases. 



- Detailed Description Text (124) : 

In one embodiment, the buyer and/or the seller can give a feedback rating and/or 
provide comments about the other participant in the transaction that some or all 
other participants can later read and/or use as search criteria 




Detailed Description Text (129) : 

In a preferred embodiment, some aggregate data (such as average payment amounts) 
are calculated dynamically, while some other aggregate data are calculated 
periodically (i.e. cached). The different calculation techniques might require 
diff erent dataJaas.eySK^ hamas , which one skilled in the art would have no difficulty 



Detailed Description Text (137) : 

Companies often need to conduct surveys of specific types of people, and it is 
currently quite expensive to do so because it is difficult to find people meeting 
the required criteria. The current invention could be used to enable companies to 
quickly find a group of qualified people to survey, and could make it easy for 
those people to fill out and submit the survey data. In this embodiment, companies 
would be able to specify which types of people qualify for the survey, from among 
t he profile in f ormatioji_j[^mogxaphic^ M ,ag^ag_ of expertise, etc.)> fhich sellers 
s^ppH^^^n*!^^*^^ custom 
surveys, and would simplify the aggregation and presentation of the survey data. In 
one embodiment, companies could provide an idea of how much they're willing to pay 
for completed surveys (e.g. a range, or a specific amount for sufficiently good 
ones and nothing for the rest, etc.) In this embodiment, the buyers would be the 
companies conducting the surveys and the sellers would be the individuals who 
filled out the surveys. As with the Web Site Testing and Feedback example, this 
example works well because the value of the information is much higher to the 
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corporation (buyer) than the surveyed person (seller), so the transaction creates 
value which the buyer and seller can both benefit from. 

Detailed Description Text (142) : 

While my above description contains many specifications, these should not be 
construed as limitations on the scope of the invention, but rather as an 
exemplification of some preferred and other embodiments thereof. Those skilled in 
the art will recognize that the method and apparatus of the present invention has 
many applications, and that the present invention is not limited to the 
representative examples disclosed herein. For example, many different embodiments 
and optional features of those embodiments are mentioned throughout this document, 
but these are by no means the only possible embodiments. Also, some of the features 
of different embodiments listed here could be combined in many ways. Moreover, the 
scope of the present invention covers conventionally known variations and 
modifications to the system components described herein, as would be known by those 
skilled in the art. Thus the scope of the invention should be determined by the 
appended claims and their legal equivalents, rather than by the examples given. 
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DOCUMENT -IDENTIFIER: US 6366910 Bl 

TITLE: Method and system for generation of hierarchical search results 



Abstract Text (1) : 

A method and system for querying hierarchically classified data. The system first 
receives a query request and then identifies classifications of the data that may 
satisfy the received query request. The system then displays the identified 
classifications. In response to selection of a displayed classification, the system 
displays sub-classifications when the selected classification has sub- 
classifications and displays the data within the classification when the selected 
classification has no sub-classifications. In another aspect, the system generates 
search results for items that are hierarchically classified. For classifications 
within the hierarchy of classifications, the system generates a search entry 
containing terms describing the items within that classification. The system then 
receives a search criteria. The system selects as initial search results those 
search entries whose terms most closely match the received search criteria. The 
system then adjusts the initial search results based on the hierarchy of 
classifications. This adjustment may include removing sub-classifications of a 
classification that is in the initial search results or adding a parent 
classification to replace multiple child classifications in the initial search 
results. 

Brief Summary Text (2) : 

The present invention relates to generating search results and, more particularly, 
to generating search results for hierarchically organized data. 

Brief Summary Text (4) : 

Many search tools are available to provide searching capability for a collection of 
data. For example, search tools are available to search for documents that may 
contain information related to a particular search criteria. Such search tools 
typically create an index of the words within each document. When the search 
criteria is received, the search tools scan the index to determine which documents 
contain the words of the search criteria. The search tools may also rank these 
documents based on various factors including the frequency of the words of the 
search criteria within the document or the presence of a word of the search 
-criteria* within' ! the title of the document. ■ * ~" ™ * v 

Brief Summary Text (5) : 

In the emerging field of electronic commerce, many thousands of products are 
available to be purchased electronically. For example, an online retailer may offer 
for sale electronic devices, major appliances, clothing, and so on. The difficulty 
a potential purchaser faces is identifying a particular product that satisfies the 
purchaser's needs. Some online retailers provide a search tool that receives a 
search criteria from a potential purchaser and searches a database containing 
information for each of the available products to identify those products that most 
closely match the search criteria. For example, a potential purchaser who is 
interested in purchasing a television may enter the search criteria of "tv." The 
search tool may identify every TV, but may also identify items such as video game 
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players and VCRs that happen to use the term "tv" in their description fields in 
the database. Thus, many products that are of no interest to the potential 
purchaser are identified. Many potential purchasers, jjwhenof acedr with, such, a^list .v 
that includes many products that are of no interest will simply shop elsewhere 
rather than wade through the list. Other online retailers may hierarchically 
organize the products so that a potential purchaser can browse through the 
hierarchy to identify the classification that contains products that are most 
likely of interest. For example, the potential purchaser may select an electronics 
device classification, a home electronics sub-classification, and a television sub- 
sub-classification. The hierarchical classification of products has several 
problems. First, many users of computer system do not fully understand the concept 
of hierarchical classifications. Thus, it is difficult for such users to use such a 
classification-based system. Second, products may not fall conveniently into any 
one classification. For example, a combination VCR and television could be 
classified as a VCR or a television. It is unlikely that an online retailer would 
have a separate classification for such a combination. Therefore, a potential 
purchaser may not even be able to locate the products of interest using a 
hierarchical classification system. 

Brief Summary Text (6) : 

It would be desirable to have a product search technique that would combined the 
advantages of the search systems and the classification-based systems and that 
minimizes their disadvantages. 

Brief Summary Text (8) : . 

Embodiments of the present invention provide a method and system for querying 
hierarchically classified data. The system of the present invention first receives 
a query request. The system then identifies classifications of the data that may. 
satisfy the received query request. The system then displays the identified 
classifications. In response to selection of a displayed classification, the system 
displays sub-classifications when the selected classification has sub- 
classifications and displays the data within the classification when the selected 
classification has no sub-classifications. 

Brief Summary Text (9) : 

In another aspect, the present invention provides a system that generates search 
results for items that are hierarchically classified. For classifications within 
the hierarchy of classifications, the system generates a search entry containing 
terms describing the items within that classification. The system then receives a 
search criteria. The system* selects as initial search results those classifications 
whose search entry has terms that most closely match the received search criteria. 
The system then adjusts the initial search results based on the hierarchy of 
classifications. This adjustment may include removing sub-classifications of a 
classification that is in the initial search results or adding a parent 
classification to replace multiple child classifications in the initial search 
results. 

Drawing Description Text (3) : 

FIG. 2 is a block diagram illustrating components of one embodiment of the GPS 
system. 

Drawing Description Text (12): 

FIG. 11 is a flow diagram of an example implementation of the GPS search engine. 
Detailed Description Text (2) : 

Embodiments of the present invention provide a method and system for general 
purpose searching ("GPS") . The GPS system allows a user to search for items that 
best match a search criteria. To facilitate the searching, the GPS system groups 
the items into a classification hierarchy. For example, if the items are articles 
of clothing, then classifications may be "shirts," "pants," and "shoes," and sub- 
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classification of "shirts" may be "T-shirts," "casual shirts," and "dress shirts." 
The GPS system inputs a search criteria from a user, searches for the 

classifications >of cite ms^. that, best-match the- search - cri-.teria^^and^displays ..those^ ^r. 
classifications in an order based on how well they match the search criteria. In 
one embodiment, the GPS system displays only the best matching classifications of 
items, rather than displaying information about any individual items. The user can 
then select a displayed classification to view the sub-classifications within that 
classification or, if that classification has no sub-classification, the items 
within that classification. 

Detailed Description Text (3) : 

When the GPS system inputs a search criteria, it scores each classification in the 
classification hierarchy to indicate the degree to which the. classification 
contains items that match the search criteria. For example, the GPS system would 
generate a score for each of the "shirts," "pants," and "shoes" classifications and 
for each of the "T-shirts," "casual shirts," and "dress shirts" sub- 
classifications. The GPS system then selects those classifications or sub- 
classifications with the highest scores and displays them in order based on their 
score. Because users often find it difficult to interface with hierarchically 
presented information, the GPS system in one embodiment displays the names of the 
selected classifications with no indication of where the classifications are within 
the hierarchy; For example, if the classifications of "dress shirts" and "shoes" 
have the highest scores, then the GPS system may simply list the classification 
names as follows : 

Detailed Description Text (8) : 

FIGS. 1A and IB illustrate an example user interface for one embodiment of the 
present invention. In this embodiment, the GPS system provides capabilities for 
searching for items that may be purchased. The techniques of the present invention 
are particularly well suited for use in a Web-based shopping environment. The 
display 100 of FIG. 1A illustrates a Web page for searching for items that may be 
purchased via an online store. This Web page illustrates x that the available item 
are grouped into five departments: clothing and accessories 101, electronics 102, 
computer hardware 103, toys and games 104, and travel 105. The item in each of 
these departments are classified into categories, sub-categories, and possibly a 
sub-sub-category referred to as item type. For example, the clothing and 
accessories department has four item categories: men's apparel, women's apparel, 
shoes, and accessories. The user enters the search criteria or query into search 
query box 106. In this example, the user has entered the word "shirts" as the 
search criteria. Display 110 of FIG. IB illustrates the display of the search 
results. Rather than displaying the particular items that best match the search 
criteria, the GPS system displays the classifications of items that best match the 
search criteria. The GPS system orders the classifications based on the likelihood 
that they contain items of interest. In this example, the GPS system determines 
that the clothing and accessories department contains items that best match the 
search criteria. As a result, the GPS system displays an indication of the clothing 
and accessories department first. The GPS system also displays the various _ 
categories arid sub-categories of the clothing and accessories department that best 
match the search criteria. The GPS system displays these categories and sub- 
categories in order based on the likelihood that the categories contain items that 
satisfies the search criteria. In this example, the GPS system has listed 10 
classifications of the clothing and accessories department. The GPS system 
highlights the first eight classifications because the word "shirts" was found in 
the sub-category name. For example, the category "Polo and henley shirts" contain 
the word "shirts" in its name. However, the last two classifications do not contain 
the word "shirts" in their sub-category names. Rather, the word "shirts" may have 
been contained in a description field for an item within those classifications. For 
example, the sub-category "Men's Ties" may have had an item that contained the word 
"shirts" in its description field. The placing of the word "shirts" in parenthesis 
indicates that the word was not found in the name of the sub-category. In general, 
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the GPS system highlights (e.g., bolds) the names of those classifications in which 
every item should satisfy the search criteria. For example, the first eight 
. di:s p lay ed - „<: 1 as s i JfiiC a t i o n s , * o f v. t h er- . c 1 o t h i n g> a n d -a c c e s s or i e.s**de p ant man t^ are - -.. l - * o-» . » ... - • * . . - - * 
highlighted. The GPS system determined that the department "travel" is the second 
most relevant department for the search criteria. The GPS system displays the 
information for the travel department after the information for the clothing and 
accessories department because the score for the classifications within the travel 
department were lower than the score for the classifications in the clothing and 
accessories department. 

Detailed Description Text (9) : 

Once the GPS system displays the search results, as shown in FIG. IB, a user may 
select one of the classifications to view detailed information about the 
classification. For example, if the user is interested in purchasing a T-shirt for 
a man, then the user may select the category "Men's T-shirts." Upon selecting this 
classification, the GPS system displays information describing the items within 
that classification. If the selected classification has sub-classifications, then 
the GPS system instead displays the sub-classifications. 

Detailed Description Text (10): 

FIG. 2 is a block diagram illustrating components of one embodiment of the GPS 
system. The GPS search system comprises a product (or item) database 201, a GPS 
index builder 202, a priority descriptor file 203, the special terms file 204, a 
browse tree descriptor file 205, a GPS index file 206, a GPS search engine 207, and 
a GPS hierarchical displayer 208. These components can be implemented as part of a 
general purpose computer system. The GPS system may be implemented as a server in a 
client/server environment such as the World Wide Web or may be implemented on a 
computer, such as a mainframe. 

Detailed Description Text (11): 

The GPS index builder creates the GPS index, which contains an entry for each 
classification, based on the names of the classifications and the content of the 
fields in the product database. The product database contains an entry for each 
item. The entries of the GPS index contain a collection of the words that appear in 
the entries of the product database for the items within that classification or the 
words in the names of the classification. After the GPS index is created, the GPS 
search engine receives a query and returns those entries whose collection of words 
most closely match the query . In one embodiment, the GPS index may contain multiple 
entries for some classifications that indicate different priorities assigned (or 
weights) based on the fields of the product database in which the terms appear. For 
example, each classification may contain one entry that contains the words from the 
name of the classification and from the name of its parent classification. The leaf 
(i.e., lowest-level) classifications, however, may also contain additional entries 
in the GPS index. One additional entry may contain all the words from all the 
description fields of all the items within the classification. Such entries are 
said to have a lower priority than entries that contain only the words in the name 
of the classifications because words in the name of a classification are assumed to 
be more descriptive of the entire classification than a word in a description field 
of some item within that classification. Each entry also contains an indication of 
its priority. 

Detailed Description Text (12): 

The GPS search engine may use a conventional database search engine to locate the 
entries of the GPS index that contain words that best match the search criteria. 
The conventional search engines return as the results of the search the entries 
that best match along with a score that indicates how well each matches. The GPS 
search engine then adjusts the scores of the entries in the result to factor in 
their priorities. For example, the GPS system may not adjust the score of an entry 
that has a high priority, but may reduce the score of an entry that has low 
priority. Once the scores are adjusted, the GPS search engine may remove all but 
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the entry with the highest score for each classification from the result. The GPS 
search engine then removes all entries for sub-classifications when an entry for an 
♦ ancestor class.ifdc-ationarinr^.thje. result.- JThat^is, the. GPS- seanch enqdne-^ensuEe.s^thafc 
if an entry for the root of a classification sub-tree is in the result, then the 
result contains no entry for any descendent classifications. The GPS search engine 
sets the score of the root classification of a sub-tree to the highest score of the 
entries for that sub-tree. The result may also contain an entry for each child 
classification but not an entry for the parent classification. In such a situation, 
the GPS search engine may remove each of the entries for the child classifications 
and adds a new entry for the parent classification. The GPS search engine may set 
the score of the new entry to the highest score of the child classifications. 

Detailed Description Text (13) : 

The GPS hierarchical displayer receives the results of the GPS search engine and 
first determines which highest level classification (e.g., department) has the 
highest score. The GPS hierarchical displayer selects those classifications with 
that highest level classification with the highest score and displays the name of 
the highest- level classification along with the names of the selected 
classification. The GPS hierarchical displayer can select a predefined number of 
such classifications or select a variable number depending on the differences in 
the scores of the classifications. The GPS hierarchical displayer then repeats this 
process for the highest level classification with the next highest score and so on. 



Detailed Description Text (15): 

The GPS index builder inputs the product database, the priority descriptor file, 
the special terms file, and the browse tree descriptor file and generates the GPS 
index file. The browse tree descriptor file contains a definition of the 
hierarchical organization of the items in the product database. Although the 
product tables inherently contain the classification hierarchy (e.g., 
classification 237 is a sub-category of classification 31) , it is not in a form 
that is easy to use. Moreover, the product database in this embodiment contains no 
information that describes the names of the various classifications. FIG. 4 
illustrates a hierarchical organization of the items in the apparel table of the 
product database. As shown, the items in the apparel table are classified into 
three levels: category, sub-category, and item type. The categories of the apparel 
table include "men's apparel" (34), "women's apparel" (35), and "shoes" (36). The 
sub-categories of men's apparel include "shirts" (272) and "outerwear" (278). The 
item types for the items within the "shirts" sub-category include "tops" (2034), 
"T-shirts" (2035), and "dress shirts" (2037). FIGS. 5A, 5B, and 5C illustrate an 
example organization of the browse tree descriptor file. The ID field contains the 
classification identifier, which correlates to the classification identifiers used 
in the product database. For example, the entry with a classification identifier of 
237 defines that classification. The parent field indicates the parent 
classification. For example, classification 31 is the parent classification of 
classification 237. The name field contains the name of the classification. For 
example, the name of classification 237 is "Beach and resorts." The ID field and 
the parent field define the classification hierarchy, and the ID field, the parent 
field, and the name field are used when building the GPS index. The other fields 
are used by the GPS hierarchical displayer when displaying the results of a search . 
The display name field contains the name that is tc be displayed when that 
classification is displayed. For example, the display name for classification 237 
is "Beach and resorts." The URL alias field identifies the resource (e.g., HTML 
file) that is displayed when the classification is selected when browsing through 
the search result. The config file field identifies a file that contains 
information for use in generating the resource for a classification. The image 
field identifies an icon that is to be displayed when the classification is 
displayed. The title image field identifies an image that is to be displayed as the 
title when a classification is selected. The table name stem file contains the name 
of the table in the product database that contains the entries for the items within 
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this classif ication. 



• De tailed D e s c r ip ti on Tiext ^(,16 u^-i&t ■ztw _ *...-«hcu*xl- * j* t u' *■ * j.v-ot?*- . ^L^^^.^^^a:^^^^ 
The priority descriptor file indicates how to score the presence of the search 
criteria in the various fields of the tables. For example, the presence of a search 
term in a category, a sub-category, or an item type name is given more weight than 
the presence of the search term in a description of the item. FIG. 6 illustrates 
the contents of a sample priority descriptor file. The priority descriptor file 
contains an entry for each department represented in the product database. For 
example, the department identified by a classification identifier of 6 is the 
clothing and accessories department as indicated by the corresponding entry in the 
browse tree description file. The priority 1 field indicates that the presence of 
tne search term in the category name, sub-category name, or item type name (e.g., 
"category. vertline. subcategory. vertline . item_type" ) should be given highest score. 
The priority 2 field indicates that the presence of the search term in the brand 
field, name field, or store field (e.g., "brand. ve rtline . name . ve rtline . store") 
should be given a lower score. The priority 3 field indicates that the presence of 
the search term in the description field or any of the other fields listed should 
be given lowest score. In one embodiment, the GPS index builder initially adds only 
one entry at priority 1 for non-leaf classifications into the GPS index. The GPS 
index builder then adds two entries at priorities 2 and . 3 for leaf classifications 
into the GPS index as discussed below. 

Detailed Description Text (17): 

FIG. 7 illustrates example contents of the special terms file. The special terms 
file lists various words (i.e., "Good Terms") that are synonymous with the 
classification names. For example, the term "blouse" is synonymous with the 
classification name "women's shirts." The file also lists various words (ie., "Bad 
Terms") that should be disregarded from the description field of the items within 
that classification. For example, the term "tv" should be disregarded when it 
occurs in the description field of a travel item. A description of a cruise may 
indicate that a "tv" is in each cabin. However, when a user enters the search term 
"tv, " the user is likely interested in elect ronic- related items rather than travel- 
related items. The special terms file may also be integrated into the browse three 
descriptor file. The GPS index builder creates GPS index entry at priority 0 for 
each entry in the special terms file that contains a good term. The GPS index 
builder also creates an entry at priority -1 for each entry in the special terms 
file that contains a bad term so that the GPS search engine will know to disregard 
classifications in which a priority -1 entry is initially reported as satisfying 
tne search criteria. 

Detailed Description Text (18): 

FIG. 8 illustrates the contents of the GPS index. The GPS index contains term table 
801 and index 802. The term table contains various entries for each classification 
within the classification hierarchy. Each entry contains an entry identifier (e.g., 
"1") , a classification identifier (e.g., "279"), a priority (e.g., n 0"), and a 
terms field (e.g., "blouse"). The terms field contains terms that the GPS index 
builder retrieves based on the priority descriptor file. For example, since 
classification 272 is in department 6, clothing and accessories, its terms field 
for its priority 1 entry contains all the terms from the fields specified in the 
priority descriptor file, that is, from the category, sub-category, and item type 
names. The index contains an entry for each word that is found in a terms field of 
the term table. Each entry contains a pointer to the entries of the term table that 
contain that term. For example, the entry for the word "shirts" in the index 
indicates that the word "shirt" is found in rows 2, 4, and 15. The term table and 
index can be created using capabilities provided by conventional databases, such as 
those provided by Oracle Corporation. 

Detailed Description Text (19): 

In one embodiment, the GPS system logs search requests along with the search 
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results and may also log which search results (i.e., classifications) are selected 
by the user. Periodically, these logs can be analyzed to determine whether synonyms 
t ..shouJxbbe...added-,ffor, a ^search^ term-.^For^example, use rs^may-. enter the s e a r c h^ t e r muc 
"aparel," rather than "apparel." Because the term "aparel" is not in the product 
database and not in the classification hierarchy, the search result will be empty. 
Therefore, it would be useful to add the term "aparel" as a synonym of "apparel." 
The GPS system provides a log analyzer to help determine when to add synonyms. In 
one embodiment, the log analyzer identifies the search requests that resulted in no 
search results or in very few classifications in the search results and displays 
the identified search requests to an analyst responsible for deciding on synonyms. 
For example, the terms of the identified search requests can be displayed along 
with a field so that the analyst can enter the word(s) with which the displayed 
search term is synonymous. The log analyzer may also display statistical 
information as to how many times the displayed search term was entered by a user. 
Also, the log analyzer may display additional information such as a subsequent 
search request entered by the same user that does return search results. The log 
analyzer may also display search requests for which the user selected none of the 
search results. In such a situation, the analyst may also want to add the search 
terms as synonyms. For example, if users enter the search request "sole" and the 
search results relate only to shoes, the analyst may want to indicate that "sole" 
is a synonym for "soul," as in music. 

Detailed Description Text (22) : 

FIG. 11 is a flow diagram of an example implementation of the GPS search engine. 
The GPS search engine is passed a query and returns the results for that query. In 
step 1101, the GPS search engine submits the query to a conventional database and 
receives the results. The results contain the identifier of entries in the term 
table along with a score for each entry. The score provides an indication of how 
closely the terms of the entry matches the search criteria. As discussed above, 
conventional databases provide such query capabilities. The query capabilities may 
support sophisticated analyses to determine the scores. The analyses may include 
using word stem analysis, word count analysis, and synonym analysis. In step 1102, 
the GPS search engine prioritizes the scores of the results that are returned. When 
prioritizing the scores, the GPS search engine removes all the entries of the 
search result for a classification and its sub-classifications when the 
classification has a priority -1 entry. For example, if the result has a priority - 
1 entry for the classification of travel (e.g., because the search term included 
"tv"), then the GPS search engine removes all entries of the search result for the 
travel classification along with entries for any of its sub-classifications. The 
GPS search engine may then remove duplicate entries for a classification (e.g. 
priority 2 or priority 3 entry) leaving the entry with the higher score. The GPS 
search engine then normalizes the score for each entry in the result to reflect the 
priority of the entry. The conventional database scores the entries independently 
of the priorities. Thus, normalizing factors the priority into the score. In one 
embodiment, the GPS search engine does not modify the scores for the priority 0 or 
1 entries. The GPS search engine does, however, divide the scores of priority 2 
entries by 4 and the scores of priority 3 entries by 9 to effect the normalization. 
One skilled in the art would appreciate that the normalization process may be 
tailored based on analysis of the scoring of the conventional database that is used 
and analysis of the priority descriptor file. One skilled in the art would also 
appreciate that a different number of levels of priorities may be used. In steps 
1103-1105, the GPS search engine loops processing each department. In step 1103, 
the GPS search engine selects the next department starting the first. In step 1104, 
if all the departments have already been selected, then the GPS search engine 
returns, else the GPS search engine continues at step 1105. In step 1105, the GPS 
search engine invokes the routine traverse to traverse the classification hierarchy 
for that department. 

Detailed Description Text (24): 

FIG. 13 into flow diagram of an example implementation of a GPS hierarchical 
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displayer routine. This routine uses the browse tree descriptor file to 
hierarchically organize the search results and to identify the configurations in 
whi c h . t o ■ d i s p 1 ay t h e ,~ r e s u 1 1 s* f o r^-ata r i- o u s^. c 1 a s s i f i c a t i o n s r. : Al t h ou g h ** not i ■* di s pi ay e d-~. i n.< > . • 
this flowchart, the GPS hierarchical displayer also receives selections of 
displayed classifications and uses the browse tree descriptor file to display sub- 
classifications if the selected classification is a non-leaf classification. If the 
classification is a leaf classification, the GPS hierarchical displayer displays 
information retrieved from the product database relating to the items in that leaf 
classification. In step 1301 the routine inputs a query from a user. In step 1302, 
the routine invokes the GPS search engine passing the query and receiving in return 
the search results. In steps 1303-1308, the routine loops displaying the search 
results. In step 1303, the routine selects the next department with an entry for 
one of its sub-classifications the next highest score that is in the results. In 
step 1304, if all the departments have already been selected, then the routine is 
done, else the routine continues at step 1305. In step 1305, the routine displays 
the department name. One skilled in the art would appreciate that this "displaying" 
may be the creating of an HTML file that is sent to a client computer to be 
displayed. In step 1306, the routine selects the entry for the selected department 
with the next highest score starting with the entry with the highest score. The 
routine may limit the number of classifications displayed for a department. For 
example, the routine may display only those classifications whose scores are above 
the average for that department. Alternatively, the routine may display only those 
classifications whose scores are within a certain deviation from the highest score 
for that department. In step 1307, if all the entries for the selected department 
have already been selected, then the routine loops to step 1303 to select the next 
department, else the routine continues at step 1308. In step 1308, routine displays 
the name of the selected entry and loops to step 1306 to select the entry with the 
next highest score. 

CLAIMS: 

1. A method in a computer system for generating search results for items that are 
hierarchically classified, the method comprising: 

providing a hierarchy of classifications; 

for classifications within the provided hierarchy of classifications, generating a 
search entry containing terms describing the items within that classification; and 

after the hierarchy of classifications is provided, 

receiving a search criteria; 

selecting as initial search results those classifications whose search entry has 
terms that most closely match the received search criteria; and 

adjusting the initial search results based on the provided hierarchy of 
classifications. 

2. The method of claim 1 wherein the adjusting includes for an entry in the initial 
search results, removing all entries that represent descendent classifications of 
that entry. 

3. The method of claim 2 wherein a score is associated with each entry in the 
initial search results and the adjusting includes adjusting the score of an entry 
when an entry for a descendent classification is removed. 

5. The method of claim 1 wherein when a classification has no entry in the initial 
search results and has entries for child classifications that surpass a threshold, 
removing the entries for the child classifications and adding an entry for the 
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classification. 



-ix.^The .meithod-.-of.^olaim^Su.whereinfi a r.s.co resist -associated. -with^ea.ch <entry;*,in. .the, . rt ...... 

initial search results and wherein the added entry is given a score based on the 
scores of the entries for the child classifications. 

8. The method of claim 1 wherein the generating includes assigning a priority to 
each search entry based on the source of the terms. 

11. The method of claim 1 wherein the adjusting of the initial search results 
include removing the entry for a classification that is selected based on negative 
terms for that classification. 

12. The method of claim 1 wherein the generating includes retrieving item entries 
for the items within the classification and adding to the search entry the terms 
from the retrieved item entries. 

16. The method of claim 1 including displaying an indication of the classifications 
of the entries in the adjusted search results. 

19. A method in a computer system for querying hierarchically classified data, the 
method comprising: 

providing a hierarchy of classifications; and 
after providing the hierarchy of classifications, 
receiving a query request; 

identifying classifications of the data that may satisfy the received query 
request; 

displaying the identified classifications; and 

in response to selection of a displayed classification, 

when the selected classification has sub-classifications, displaying sub- 
classifications; and 

when the selected classification has no sub-classifications, displaying the data 
within the classification. 

21. The method of claim 19 wherein when sufficient sub-classifications of a 
classification may satisfy the received query request, identifying the 
classification rather than the sub-classifications. 

22. The method of claim 21 wherein classifications have scores based on how well 
they may satisfy the received query request and wherein the classification that is 
identified rather than the sub-classifications is assigned a score based on the 
scored of its sub-classifications. 

25. The method of claim 19 including: 

for classifications within the hierarchy of classifications, generating a search 
entry containing terms describing the data within that classification; and 

wherein the identifying includes: 

selecting as initial query results those search entries whose terms most closely 
match the received query request; and 
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identifying classifications of the selected search entries based on the hierarchy 

26. A method in a computer system for specifying relevance of search terms within a 
classification of data that is hierarchically classified, the method comprising: 

providing a negative term for at least one classification; 

receiving a query request having requested terms; and 

generating a result for the received query request wherein the one classification 
is not included in the result when the negative term is a requested term. 

29. The method of claim 26 wherein the one classification is not included 
regardless of how well the one classification might otherwise satisfy the query 
request. 

30. A method in a computer system for determining whether hierarchical 
classifications of data satisfy a query request, the method comprising: 

providing a priority descriptor that specifies how to determine terms that are 
relevant to a classification; 

determining terms that are relevant to classifications based on the priority 
descriptor; and 

identifying those classifications that most closely match the query request based 
on review of the determined terms for the classifications. 

34. The method of claim 30 wherein the determined terms are stored in a term table 
before receiving the query request and wherein the identifying is performed by 
reviewing the term table. 

35. A computer-readable medium containing instructions for causing a computer 
system to generate search results for items that are hierarchically classified, by 
a method comprising: 

providing a hierarchy of classifications, 

for classifications within the provided hierarchy of classifications, identifying 
terms describing the items within that classification; and 

after the hierarchy of classifications is provided, 

receiving a search criteria; 

selecting as initial search results those classifications whose identified terms 
most closely match the received search criteria; and 

adjusting the initial search results based on the hierarchy of classifications. 

36. The computer-readable medium of claim 35 wherein the adjusting includes for 
each classification in the initial search results, removing all descendent 
classifications. 

37. The computer-readable medium of claim 36 wherein a score is associated with 
each classification in the initial search results and the adjusting includes 
adjusting the score of a classification when a descendent classification is 
removed. 
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39. The computer-readable medium of claim 35 wherein when a classification is not 
^in r .the^initial^ -3earchv .resultswand ehi.ld .classif ications ^ace .iin^the. initial search- 

results and surpass a threshold, removing the child classifications and adding the 
classification. 

40. The computer-readable medium of claim 39 wherein a score is associated with 
each classification in the initial search results and wherein the added 
classification is given a score based on the scores of the child classifications. 

45. The computer-readable medium of claim 35 wherein the adjusting of the initial 
search results include removing the classification that is selected based on 
negative terms for that classification. 

50. The computer-readable medium of claim 35 including displaying an indication of 
the classifications in the adjusted search results. 

53. A computer-readable medium containing instructions for causing a computer 
system to query a hierarchically classified data, by a method comprising: 

providing a hierarchy of classifications; and 

after the hierarchy of classifications is provided, 

identifying classifications of the data that may satisfy a query request; 
displaying the identified classifications; and 

in response to selection of a displayed classification, displaying sub- 
classifications or displaying the data within the classification. 

55. The computer-readable medium of claim 53 wherein when sufficient sub- 
classifications of a classification may satisfy the received query request, 
identifying the classification rather than the sub-classifications. 

56. The computer-readable medium of claim 55 wherein classifications have scores 
based on how well they may satisfy the query request and the classification that is 
identified rather than the sub-classifications is assigned a score based on the 
score of its sub-classifications. 

59. The computer-readable medium of claim 53 including: 

for classifications within the hierarchy of classifications, generating a search 
entry containing terms describing the data within that classification; and 

wherein the identifying includes: 

selecting as initial query results those search entries whose terms most closely 
match the received query request; and 

identifying classifications of the selected search entries based on the hierarchy 
of classifications. 
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